Release automation#1172
Conversation
PatelUtkarsh
left a comment
PatelUtkarsh
left a comment
There was a problem hiding this comment.
Left some suggestions but overall looks good!
|
|
||
| # After the deployment, we also want to create a zip and upload it to the release on GitHub. | ||
| - name: Upload release asset | ||
| uses: actions/upload-release-asset@v1 |
There was a problem hiding this comment.
💡 thought: This action is archived and deprecated by GitHub since 2021.
Should we migrate it to more active ones like:
- name: Upload release asset
uses: softprops/action-gh-release@v2
with:
files: ${{ steps.deploy.outputs.zip-path }}
|
|
||
| # Install dependencies. | ||
| - name: Install NPM dependencies | ||
| run: npm install |
There was a problem hiding this comment.
💬 suggestion: In CI we use npm ci we can keep it same here.
| run: npm install | |
| run: npm ci |
|
|
||
| # Build. | ||
| - name: Build | ||
| run: npm run build |
There was a problem hiding this comment.
💬 suggestion: The release pipeline trusts that the human releaser bumped .version, package.json, and readme.txt to match the tag they're publishing. There's nothing here to fail the build if git tag == "3.3.4" but .version == "3.3.3". Given the PR explicitly notes the human has to remember to update both files, a 5-line sanity check is cheap insurance:
- name: Verify version matches tag
run: |
TAG="${GITHUB_REF_NAME#v}"
FILE_VERSION=$(cat .version | tr -d '[:space:]')
if [ "$TAG" != "$FILE_VERSION" ]; then
echo "::error::Tag $TAG does not match .version $FILE_VERSION"
exit 1
fi
| on: | ||
| push: | ||
| workflow_call: | ||
| pull_request: |
There was a problem hiding this comment.
💬 suggestion: With push: and pull_request: and workflow_call: here every PR push fires CI twice (once for the push event on the branch, once for the PR). This isn't introduced by this PR but the workflow_call addition is a good moment to audit. Suggestion (out of scope, but worth a follow-up): scope push: to branches: [develop, master].
| runs-on: ubuntu-22.04 | ||
| permissions: | ||
| contents: write | ||
| packages: read |
There was a problem hiding this comment.
💬 suggestion: Is this required? if not we can clean it up.
3 participants
Deployment process
This is what the production release process will look like from now on:
1. Prepare master branch
This is pretty much as before:
master.versionandpackage.jsonreadme.txtchangelog2 Create and publish GH release
This is also similar to what was done before:
masterreadme.txt)3. The GH workflow
Publishing the release will automatically trigger
.github/workflows/deploy-to-wp-org.yml, which:npm run build)build/and update version references (viagrunt prepare)trunk/, createstags/<version>/, and updatesassets/QA notes